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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 2 of the LoCation Services (LCS) feature in UTRAN, which provides the 
mechanisms to support mobile location services for operators, subscribers and third party service providers. 

The purpose of this stage2 specification is to define the UTRAN LCS architecture, functional entities and operations to 
support location methods. This description is confined to the aspects of LCS within the UTRAN and does not define nor 
describe the LCS entities or operations within the Core Network. 

Location Services may be considered as a network provided enabling technology consisting of standardised service 
capabilities, which enable the provision of location applications. The application(s) may be service provider specific. 
The description of the numerous and varied possible location applications which are enabled by this technology are 
outside the scope of the present document. However, clarifying examples of how the functionality being described may 
be used to provide specific location services may be included. 

This stage 2 specification covers the UTRAN LCS functional model and entities, the location methods, state 
descriptions, and message flows. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

2.1 Normative references 

[I] 3GPP TS 23.171: "Functional stage 2 description of location services in UMTS". 

[2] 3GPP TS 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[3] Technical Specification Group Services and System Aspects Service aspects; Terminology and 

Vocabulary within TSG-Sl: Report and Recommendations, 28.7.99. 

[4] 3GPP TS 02.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); Service description. Stage 1". 

[5] 3GPP TS 03.71: "Digital cellular telecommunications system (Phase 2+); Location Services 

(LCS); (Functional description) - Stage 2". 

[6] 3GPP TS 03.32: "Universal Geographical Area Description". 

[7] 3GPP TS 22.100: "UMTS phase 1 Release 99". 

[8] 3GPP TS 22.101: "Service principles". 

[9] 3GPP TS 22.105: "Services and Service Capabilities". 

[10] 3GPPTS 22.115: "Charging and Billing". 

[II] 3GPP TS 22.121: "The Virtual Home Environment". 

[12] 3GPP TS 23.1 10: "UMTS Access Stratum; Services and Functions". 

[13] 3GPP TS 25.413: "UTRAN lu interface RANAP signalhng". 
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[14] 3GPP TS 25.423: "UTRAN lur interface RNSAP signalling". 

[15] 3GPP TS 25.433: "UTRAN lub interface NBAP signalling". 

[16] 3GPP TS 25.214: "Physical layer procedures (FDD)" 

[17] 3GPP TS 25.215: "Physical layer - Measurements (FDD)". 

[18] 3GPP TS 25.225: "Physical layer - Measurements (TDD)". 

[19] 3GPP TS 25.331: "RRC protocol specification". 

[20] 3GPP TS 23.032: "Universal Geographical Description (GAD)". 

2.2 Informative references 

[21] Third generation (3G) mobile communication system; Technical study report on the location 

services and technologies, ARIB ST9 December 1998. 

[22] The North American Interest Group of the GSM MoU ASSOCIATION: Location Based Services, 

Service Requirements Document of the Services Working Group. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.101 and some of the terms 
and definitions in annex A apply. 

3.2 Abbreviations 

For the purposes of the present document, the GSM-related abbreviations given in GSM 01.04 and the UMTS-related 
abbreviations given in UMTS TS 22.101 apply. 



IVIain concepts 



A general description of location services and the service requirements is given in the specification 3GPP TS 22.071 
[4]. 

By measuring radio signals the capability to determine the geographic location of the user equipment (UE) shall be 
provided. The location information may be requested by and reported to a client (application) associated with the UE, or 
by a client within or attached to the Core Network. The location information may also be utilised internally by UTRAN, 
for example, for location assisted handover or to support other features such as home location billing. The location 
information shall be reported in standard formats, such as those for cell based or geographical co-ordinates, together 
with the time-of-day and the estimated errors (uncertainty) of the location of the UE. 

It shall be possible for the majority of the UE (active or idle) within a network to use the feature without compromising 
the radio transmission or signalling capabilities of the UTRAN. 

The uncertainty of the location measurement shall be network design (implementation) dependent at the choice of the 
network operator. The uncertainty may vary between networks as well as from one area within a network to another. 
The uncertainty may be hundreds of metres in some areas and only a few metres in others. In the event that the location 
measurement is also a UE assisted process, the uncertainty may also depend on the capabilities of the UE. In some 
jurisdictions, there is a regulatory requirement for location service accuracy that is part of an emergency service. Further 
details of the accuracy requirements can be found in [4] . 
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The uncertainty of the location information is dependent on the method used, the location of the UE within the coverage 
area and the idle or active state of the UE. Several design options of the UTRAN system (e.g. size of cell, adaptive 
antenna technique, path loss estimation, timing accuracy, base station surveys) shall allow the network operator to 
choose a suitable and cost effective location service feature for their market. 

There are many different possible uses for the location information. The location feature may be used internally by the 
UTRAN network (or attached networks), by value-added network services, by the UE itself or through the network, and 
by "third party" services. The feature may also be used by an emergency service (which may be mandated or "value- 
added"), but the location service is not exclusively for emergencies. 

The UTRAN is a new radio system design without a pre-existing deployment of UE operating according to the air 
interface. This freedom from legacy equipment enables the location service feature design to make use of appropriate 
techniques to provide the most accurate results. The technique must also be a cost-effective total solution, must allow 
evolution to meet evolving service requirements and be able to take advantage of advances in technology over the 
lifetime of UTRAN deployments. 

4.1 Assumptions 

As a basis for the operation of LCS in UTRAN the following assumptions apply: 



the UE must support SFN-SFN observed time difference type 2 measurements, thus support of network based 
OTDOA without idle periods is mandatory in the UE. 

- both, TDD and FDD will be supported in release '99;- the provision of the location service in UTRAN is 
optional through support of the specified method(s) in Node-B and the CRNC; 

LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on choice of 
location method or notification of a location request to the UE user when LCS or individual location methods, 
respectively, are not supported by the UE; 

RNC contains SMLC functionality and LCS information is transported between RNCs via the lur interface; 

LCS shall be applicable for both circuit switched and packet switched services; 

the location information may be used for internal system operations to improve system performance; 

there are different types of LMU, e.g. a standalone LMU and/or LMU integrated in Node B; 

the location process shall include the option to accommodate several techniques of measurement and processing 
to ensure evolution to follow changing service requirements and to take advantage of advancing technology. 

4.2 Location Services Categories 

Generally there are four categories of usage of the location service: 

- the Commercial LCS (or Value Added Services); 

- the Internal LCS; 

- the Emergency LCS; 

- the Lawful Intercept LCS. 

These location services categories are further defined in [1] and [4]. 



4.3 Locating IVIethods 



The LCS feature utilises one or more location methods in order to determine the location of User Equipment (UE) or 
Mobile Stations. Locating the UE involves two main steps: 
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signal measurements; and 

location estimate computation based on the measurements. 

The signal measurements may be made by the UE, the Node B or a dedicated location measuring unit (LMU). The basic 
signals measured are typically the UTRA radio transmissions, however, some methods may make use of other 
transmissions such as general radio navigation signals. 

In addition the location service should not be limited to a single method or measurement. That is, it should be capable of 
utilising other standard methods and measurements, as are available and appropriate, to meet the required service needs 
of the location service client. This additional information could consist of readily available UTRAN measurements such 
as RTT in FDD or Rx Timing deviation measurement and knowledge of the UE timing advance, in TDD. 

The location estimate computation may be made in the UE or by a calculation function located in the UTRAN. 

4.4 Standard LCS Methods 

The standard LCS methods supported within UMTS are:: 

cell ID based method; 

OTDOA method with network configurable idle periods (the idle period configurability is to be specified in the 
specification); and 

network assisted GPS methods. 

NOTE: GPS based solutions are being standardised in TlPl; it is intended that the UTRAN navigational assisted 
solution will be synergistic with the work in TlPl. 

4.4.1 Cell ID Based Method 

In the cell ID based (i.e. cell coverage) method the location of an UE is estimated with the knowledge of its serving 
node-B. The information about the serving node-B and cell may be obtained by paging, locating area update, cell 
update, URA update, or routing area update. 

The cell coverage based location information can be indicated as the Cell Identity of the used cell, the Service area 
identity or as the geographical co-ordinates of a location related to the serving cell. The location information shall 
include a QoS estimate (e.g. regarding achieved accuracy). 

When geographical co-ordinates are used as the location information, the estimated location of the UE can be a fixed 
geographical location within the serving cell (e.g. location of the serving node-B), the geographical centre of the serving 
cell coverage area, or some other fixed location within the cell coverage area. The geographical location can also be 
obtained by combining information on the cell specific fixed geographical location with some other available 
information, such as the signal Round Trip Time (RTT) in FDD (as specified in [17]) or Rx Timing deviation 
measurement (as specified in [18]) and knowledge of the UE timing advance, in TDD. 

The operation of the cell ID based location method is described in clause 8. 

4.4.2 OTDOA-IPDL Method with network configurable idle periods 

The OTDOA-IPDL (Observed Time Difference Of Arrival with optional Idle Periods in the DownLink) method 
involves measurements made by the UE and LMU of the UTRAN frame timing (e.g. SFN-SFN observed time 
difference). These measures are then sent to a Position Calculation Function (PCF) in the Serving RNC where the 
location of the UE is calculated. 

The simplest case of OTDOA-IPDL is without idle periods. In this case the method can be referred to as simply 
OTDOA. 

The Node Bs may provide idle periods in the downlink, in order to potentially improve the hearability of other Cells. 
The support of these idle periods in the UE is optional. Support of idle periods in the UE means that its OTDOA 
performance will improve when idle periods are available. 
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Optionally, a PCF may be included in the UE, in which case the calculation of the location from the measurements may 
alternatively be performed in the UE. 

The detailed description of the OTDOA-IPDL location method and its operation are described in clause 9. 

4.4.3 Network Assisted GPS Methods 

These methods make use of UEs which are equipped with radio receivers capable of receiving signals from the Global 
Positioning System (GPS). 

The operation of the network assisted GPS methods is described in clause 10. 



5 UTRAN LCS Architecture 

Figure 5.1 shows the general arrangement of the Location Service feature. This illustrates, generally, the relation of 
LCS Clients and servers in the core network with the UTRAN. The definition and operation of LCS entities operating in 
the core network is outside the scope of the present document. The LCS entities within the UTRAN communicate with 
the Core Network (CN) across the lu interface. Communication among the UTRAN LCS entities makes use of the 
messaging and signalling capabilities of the UTRAN. 

As part of their service or operation, the LCS Clients may request the location information of User Equipment (UE) 
(UE without a valid SIM/USIM) or mobile stations. There may be more than one LCS client. These may be associated 
with the core network, associated with the UTRAN, operated as part of a UE application or accessed by the UE through 
its access to an application (e.g. through the Internet). 

Within the UTRAN, typically the serving RNC, receives authenticated requests for LCS information from the core 
network across the lu interface. LCS entities then manage the UTRAN resources, including the Node-Bs (base stations), 
LMU, the UE and calculation functions, to estimate the location of the UE and return the result to the CN. 
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NOTE: This figure is taken from TS 23.002, Network Arcfnitecture. 

Figure 5.1 : General arrangement of LCS in UIUITS 
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5.1 LCS Operations 



The schematic functional description of LCS operations in UMTS is defined in [1]. 

Upon request from the UMTS LCS entities or for internal operations, the UTRAN LCS functional entities will: 

- request measurements, typically from the UE and one or more Node-B radio apparatus; 
send the measurement results to the appropriate calculating function within UTRAN; 

- receive the result from the calculating function within UTRAN; 

- perform any needed co-ordinate transformations; 

send the results to the LCS entities in the core network or to application entities within UTRAN. 

In the event that the client is internal to UTRAN the request may be made directly to the UTRAN LCS entities as the 
internal clients are considered to be "pre-authorised". 

As part of its operation, the UTRAN LCS calculating function may require additional information. This may be 
obtained by the function directly by communication with a database, or it may be through a request to UTRAN LCS 
entities that will mediate the request and return of information from the appropriate database (or databases if more than 
one is needed to fulfil the requests). 

There may possibly also be available independent information that is able to supply the location information directly, or 
may be able to supply auxiliary information to the calculation function. The UTRAN LCS co-ordination function, as 
part of its activity to supervise the location process, may query the UE or other elements of the UTRAN to determine 
their capabilities and use this information to select the mode of operation. 

This general operation is outlined in the following (generic) sequence diagram figure 5.2. This figure is not intended to 
show the complete LCS operation for UTRAN, but to simply to outline the basis for operation. 



CNLCS 
Entities 



UTRAN 
Entities 



Coordination 



IVIeasurement 



Calculation 



Location 



Request 



Location 



Response 



measure request 



measurements 



calculation request 



calculation results 



Figure 5.2: General sequence for LCS operation 



5.2 High-Level Functions 



Several functional groupings may be defined to describe the LCS. These groupings occur in both the Core Network and 
the UTRAN. The overall LCS functional grouping is described in reference [1]. Each grouping encompasses a number 
of functional components and functions. 

The functions within the UTRAN are described in more detail in the following subclauses of the present document. 

Within UTRAN the functional entities may be grouped as follows: 
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the Internal Client group; 
- the UTRAN System Handling group; 
the Positioning group. 

5.2.1 Co-ordination, Measurement and Calculation Functions 

These UTRAN functions (including functions in the System handling and Positioning groups) provide the 
co-ordination, measurement and calculation functions needed to provide a location estimate. The functions interface 
with the requesting application and select the appropriate location method and speed of response. The functions 
co-ordinate the operations of the radio and measurement equipment to transmit the needed signals and to make the 
needed measurements. The measurements may be made by Node-Bs, radio apparatus associated with the Node-B or 
separate Location Measurement Units (LMU) that may be associated with Node-B, independently located or remote 
(i.e. communicating over the Uu interface). 

The functions may also access databases or other sources of information appropriate for the location method. The 
functions also provide the calculation functions appropriate for the location method to estimate the UE location and the 
accuracy of the report. The functions may also make co-ordinate translations to the geographic co-ordinate system 
requested by the application. The functions also may record information on the usage of the LCS that may be used for 
administrative purposes (e.g. forwarded to a billing function in the Core Network). If needed by the location method, 
the functions will ensure the broadcast of information and gather and update information concerning UTRAN operating 
parameters (e.g. timing of Node-B transmissions) needed for LCS operations. 

These entities are mainly concerned with the location method, controlling the radio equipment and performing the 
calculations to determine the location and thus may be associated with the RNC in the UTRA access network. These 
functions may receive location requests from either the core network or from applications internal to the UTRAN. 

The UTRAN LCS entities may also request the subscription and authorisation functions in the core network to 
authenticate an application or a UE subscription or to verify the subscriber privacy parameters. 

These functions communicate with the core network across the lu interface, with other entities in the UTRAN across the 
lur interface and with the Node-B and LMU across the lub interface and with the UE and the remote LMU across the 
Uu interface. 

5.3 UTRAN LCS Functional Entities 

The diagram of the UTRAN LCS functional entities is shown in figure 5.3. In this arrangement, the LCS clients in the 
core network communicate with the UTRAN LCS entities across the lu interface. The LCS RNC Handling Entities and 
the Positioning Handing Entities work together with the UE to measure and calculate the location information for the 
requested target UE. These entities within the UTRAN are described in more detail in the following subclauses. 

The figure shows the general arrangement of the Location Service feature in UTRAN. LCS entities are added to the 
UTRAN to provide the location service. Communication among these entities makes use of the messaging and 
signalling capabilities of the UTRAN across the lu, lur, lub and Uu interfaces. A Location Measurement Unit (LMU) is 
also added to the UTRAN to make measurements as needed by the selected location method. 

This figure does not include elements of the next generation mobile Core Network, but focuses on those that participate 
with the LCS functions in the UTRAN. The association of the LCS entities within the Core Network (CN) (e.g. with 
3G-MSC or 3G-SGSN) is outside the scope of the present document and is not illustrated in the diagram. 

Within the UTRAN, the LCS Entities may be associated with, or part of the RNC, the Node-B and the UE. Internal LCS 
Applications may also be part of the RNC and the UE. 

The mobile position calculation function (PCF) is logically associated with the Serving RNC in UTRAN. 

The LCS in UMTS also makes use of the standardised lur interface between RNCs, when base station information, 
measurements and results are collected. 

The functional model presented in the figure includes functional entities for UE utilising either or both circuit switched 
(CS) and packet switched (PS) services. This model also supports of all the entities needed for different location 
methods (e.g. network based, mobile based, mobile assisted, and network assisted (see note 1) methods) exploiting 
either uplink or downlink measurements. 



£75/ 



3GPP TS 25.305 version 3.3.0 Release 1999 



13 



ETSI TS 125 305 V3.3.0 (2000-09) 



NOTE 1 : In this approach mobile station may use the GPS technique but still make use of auxiliary information 
from the serving network. 

Implementations may often associate the UTRAN LCS Entities with an RNC (as illustrated in the figure). However, for 
networks with a small volume of LCS requests, the LCS Entities in the UTRAN may also be implemented as a separate 
element (server) which interfaces with the RNCs, and the Node-B/LMUs. 



LMU (remote) 




External ' 

LCS v-fL.. 
Application 



Uu 



UTRAN LCS Entities 



c 



D-RNC 



lur 




Positioning 

Handling 

Entities 



r 

\ PRCF ,: 



iPRRM ' 



lub 



5_ 

(PSMF } 



L 



Node-B, LMU 



Location 
Service 
Request 



Location 
Service 
Response 



Core Network (CN) 

LCS Entities 
(Client, Subscriber) 



J 



Figure 5.3: UTRAN LCS Functional Entities 



5.3.1 Internal Client Group 



5.3.1.1 



Internal UTRAN Location Client Function (U-LCF) 



The Location Client Function (U-LCF) represents a logical interface between the internal UTRAN LCS applications 
and the LCS RNC Handling entities (e.g. the Location System Control Function (U-LSCF) in the RNC). 

NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the UTRAN 
Internal Client as is described for external clients in reference [1] (the system stage specification). 

The UTRAN may make use of location information for internal operations such as location assisted handover. In such a 
case, a U-LCF representing the internal UTRAN LCS application may communicate with the U-LSCF to request and 
receive the location information. 



5.3.2 UTRAN System Handling group 



5.3.2.1 



UTRAN Location System Control Function (U-LSCF) 



The UTRAN Location System Control Function in RNC is responsible for co-ordinating location requests within the 
RNC handling entity. This function manages call-related and non-call-related location requests and allocates network 
resources for handling them. This function "insulates" the Location clients in the Core Network from the detailed 
operation of the location method in order that the UTRAN may be used by several types of core network and with 
several location methods. 

The U-LSCF provides flow control between simultaneous location requests. Simultaneous location requests must be 
queued in a controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow 
control, priority selection and queuing are beyond the scope of the present document. 
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The U-LSCF will select the appropriate location method based on the availability of resources and parameters of the 
location request. The U-LSCF co-ordinates resources and activities needed to obtain data (e.g. base station geographic 
co-ordinates) needed for the location method. It also records LCS RNC usage data for the location service request that 
may be passed to a Location System Recording Function (U-LSRF) or OA&M function in the Core Network. 

If the location technique requires the broadcast of system information, the LSCF initiates and maintains this activity 
through the Position Radio Co-ordination Function (U-PRCF). Broadcast information (such as the geographic co- 
ordinates of the base stations) may be required, for example, to support a Position Calculation Function (U-PCF) 
located in the mobile unit (UE). These broadcasts may also include other information (such as currently observable 
satellites) that may assist a UE in the use of external location services. 

The information to be broadcast is selected based on the location techniques offered for use by the LCS and the needs of 
the UE. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to subscribers 
of the service. The use of broadcasts or other methods for signalling to the UE or the LMU may be selected based on 
the chosen location method. 

The information to be broadcast could include, for example: 

identification and spreading codes of the neighbouring base stations (the channels that are used for 
measurements); 

Relative Time Difference (RTD), i.e. the timing offsets, asynchronity between base stations, could be based on 
measurement results obtained by LMUs; 

- roundtrip delay estimates in connected mode; 

the geographic location, co-ordinates, of the neighbouring base stations; 

the idle period places within the frame structure for multiple base stations; 

the local time-of-day. 

Some of this information may be broadcast to support other UTRAN operations (e.g. handover). The function of the 
LSCF is to ensure information is broadcast when needed for the LCS operations and the LSCF may make use of other 
UTRAN processes to do so. 

If there are frequency differences between the (unsynchronised) base stations, the OTDOA measurements must be 
reported together with the time-of-day they were made (timestamp). This is necessary so that the appropriate value of 
the RTD may be used by the calculation function. 

5.3.2.2 UTRAN Location System Operations Function (U-LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, location capabilities, data 
related to clients and subscription (LCS client data and UE data), fault management and performance management of 
LCS within the RNC. 

An LSOF may be associated with each entity. The LSOF interacts with Internal (OAM) Clients for administration and 
maintenance of the data. 

5.3.3 Positioning group 

5.3.3.1 UTRAN Position Radio Co-ordination Function (U-PRCF) 

The UTRAN Position Radio Control Function manages a location request for a UE through overall co-ordination and 
scheduling of resources to perform location measurements. This function interfaces with the U-PSMF, the U-PRRM 
and the U-PCF. The U-PRCF determines the location method to be used based on the location request, the QoS, the 
capabilities of the UTRAN, and the UE's capabilities. The U-PRCF also manages the needed radio resources through 
the U-PRRM. It determines which U-PSMFs are to be involved, what to measure, and obtains processed signal 
measurements from the U-PSMF. 

Some location methods may involve measurements made at the UE. In this case the U-PRCF interfaces with the UE to 
obtain the measurements (or the location results if they have been determined by the UE). Some location methods may 
involve measurements or information from several sources, including radio units at several Node-B (or other Location 
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Measurement Units (LMU)) and involve a series of transmissions and receptions. The U-PRCF entity also provide 
ancillary measurements in case of network-assisted location method. Ancillary information may be extracted from 
navigating systems like GPS. 

The U-PRCF forwards the signal measurement data to the U-PCF. 

It is the function of the U-PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to 
provide the location estimate. 

5.3.3.2 UTRAN Position Calculation Function (U-PCF) 

The UTRAN Position Calculation Function is responsible for calculating the location of the UE (mobile unit). This 
function applies an algorithmic computation on the collected signal measurements to compute the final location 
estimate and accuracy. 

The U-PCF may also support conversion of the location estimate between different geographic reference systems. It 
may obtain related data (e.g.: base station geographic co-ordinates) needed for the calculation. There may be more than 
one calculating function available within, or associated with, the calculation function of the UTRAN. 

In the cell ID based location method, the U-PCF shall determine the geographical co-ordinates corresponding to the 
cell(s) associated with the the target UE. 

The Position Calculation Function is also responsible for estimating the accuracy of the location estimate. This accuracy 
estimate should include, for example, the effect of geometric dilution of precision (GDOP), the capabilities of the signal 
measuring hardware, the effects of multipath propagation and the effects of timing and synchronisation unknowns. The 
accuracy should be returned as a measure of distance in the same units as the location estimate. The accuracy zone may 
be reported as the axis and orientation of an ellipse surrounding the location estimate. 

5.3.3.3 UTRAN Position Signal Measurement Function (U-PSMF) 

The UTRAN Position Signal Measurement Function (U-PSMF) is responsible for performing and gathering uplink or 
downlink radio signal measurements for use in the calculation of a UE's location. These measurements can be location 
related or ancillary. 

There may be one or more PSMF within a UTRAN and they may be located at the UE, the Node-B, or a separate 
Location Measurement Unit (LMU). The PSMF, generally, may provide measurement of signals (i.e. satellite signals) 
in addition to measurements of the UTRA radio transmissions. The measurements to be made will depend on the 
selected location method. 

5.3.3.4 UTRAN Position Radio Resource Management (U-PRRM) 

The UTRAN Position Radio Resource Management entity is responsible for managing the effect of LCS operations on 
the overall performance of the radio network. This may ensure, for example, that the operation of the U-PSMF does not 
degrade the QoS of other calls. The U-PRRM handles following functions: 

controlling the variation of the UL and DL signal power level due to the LCS application; 

calculating the DL and UL power/interference due to UE location operations; 

to admit/reject the new LCS requests; 

co-operating with Admission Control, and entities of the RRM (such as power control) to provide the system 
stability in terms of radio resources; 

controlling the RTD measurement mechanism. It may also forward the results of the RTD; ATD (or any similar 
timing parameter) measurements to the PRCF (or PCF); 

controlling the IPDL mechanism for location measurements. This may include the overall control of the 
periodical measurement fulfilment. Co-ordination among RNC (e.g. to assure non-overlapping idle periods) will 
be communicated through the lur interface. 
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5.4 Assignment of LCS Functional Entities to UTRAN Elements 

The preceding figure 5.3 and the following table 5.1 show the generic configuration for different location methods, 
including network-based, mobile-based, mobile-assisted and network-assisted methods. With this approach both the 
network and the mobiles are able to measure the timing of signals and compute the mobile's location estimate. 
Depending on the applied location method it is possible to utilise the corresponding configuration containing all needed 
entities. For instance, if a network-based location method is applied, the entities that are involved in measuring the 
mobile's signal and calculating its location estimate are allocated to the network elements of the access stratum. On the 
other hand, in case mobile-based or network-assisted methods are used these entities should be allocated to the mobile 
station. 

Table 5.1 : Example Allocation of LCS Functional Entities to Network Elements 
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5.5 Functional Description of UTRAN LCS Network elements 
5.5.1 Radio Network Controller (RNC) 



5.5.1.1 



Serving RNC 



The Serving RNC (SRNC) is a network element of UTRAN and contains functionality required to support LCS in one 
PLMN. 

The SRNC manages the overall co-ordination and scheduling of resources required for the location of a mobile. It also 
calculates the final location estimate and estimates the achieved accuracy. 

The SRNC may control a number of LMUs for the purpose of obtaining radio interface measurements to locate or help 
locate MS subscribers in the area that it serves. The SRNC is administered with the capabilities and types of 
measurement produced by each of its LMUs. Signalling between an SRNC and LMU is transferred using the lub 
interface, sometimes the lur interface. The following measurements returned by an LMU to an SRNC have a generic 
status in being usable for more than one location method: 

- radio interface timing information. 

The SRNC and GMLC are connected through the 3G-VMSC or 3G-SGSN. When the VMSC and GMLC are in 
different PLMNs, they are interconnected via the Lg interface. 

5.5.1.2 Other RNC 



5.5.1.2.1 



Controlling RNC 



The Controlling RNC is a UTRAN element that has the role to control Node-B s. The controlling RNC may ask its 
associated NodeBs and LMUs for LCS measurements. The measurement results are delivered from the LMUs to the 
Controlling RNC that then forwards the results to the serving RNC. 



5.5.1.2.2 



Drift RNC 



Drift RNC is a UTRAN element that has active link to the UE that shall be located. Drift RNC may ask its associated 
NodeBs for LCS measurements. The measurement results are delivered from the NodeBs and to the Drift RNC that then 
forwards the results to the serving RNC. 
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5.5.2 NodeB 

Node B is a network element of UTRAN that may provide measurement results for location estimation. It contains a 
PSMF and makes measurements of radio signals and communicates these measurements to the SRNC. 

The Node B may make its measurements in response to requests (e.g. from the SRNC), or it may autonomously 
measure and report regularly or when there are significant changes in radio conditions (e.g. changes in the RTD). 

5.5.3 Location measurement unit (LMU) 

The LCS Measurement Unit (LMU) entity makes measurements (e.g. of radio signals) and communicates these 
measurements to the S-RNC (e.g. the PRCF). The LMU contains a PSMF and may also perform calculations associated 
with the measurements. 

The LMU may make its measurements in response to requests (e.g. from the S-RNC (e.g. the PRCF)), or it may 
autonomously measure and report regularly (e.g. timing of Node-B transmissions) or when there are significant changes 
in radio conditions (e.g. changes in the RTD). 

There may be one or more LMU associated with the UTRAN and an LCS request may involve measurements by one or 
more LMU. The LMU may be of several types and the S-RNC will select the appropriate LMUs depending on the LCS 
method being used. 

The LMU may be used, for example, to measure UTRA transmissions either uplink or downlink. These measurements 
may be made either, for example, to locate the UE or to measure a system parameter needed by the LCS system such as 
the timing offset (RTD) of transmissions of two or more base stations. The LMU may also measure other transmissions, 
such as those of satellite navigation systems (i.e. the Global Position System (GPS)) and either report the measurements 
for use by the S-RNC (e.g. the PCF), or report the location results as determined by internal calculations of the LMU). 
The details of the measurements to be made by the LMU will be defined by the chosen LCS method. 

An LMU makes radio measurements to support one or more location methods. These measurements fall into one of two 
categories: 

(a) location measurements specific to one UE and used to compute its location; 

(b) assistance measurements applicable to all UEs in a certain geographic area. 

All location and assistance measurements obtained by an LMU are supplied to a particular S-RNC associated with the 
LMU. Instructions concerning the timing, the nature and any periodicity of these measurements are either provided by 
the S-RNC or are pre-administered in the S-RNC (e.g. using O&M). 

There are two classes of LMU: 

Stand-Alone LMU: accessed over the UTRAN air interface; 

- Associated LMU: accessed over the lub interface. 

The associated LMU signalling protocol is the NBAP. The protocol for stand-alone LMU signalling has not been 
defined yet. 

NOTE 1 : The stand-alone LMU signalling protocol could be, for example, RRC or LLP, but this is still for further 
study. 

Stand-Alone LMU 

A stand-alone LMU is accessed exclusively over the UTRAN air interface (Uu interface). There is no other connection 
from the stand-alone LMU to any other UTRAN network element. 

NOTE 2: This does not preclude a stand-alone LMU from also communicating with other networks (e.g. GSM) 
through interfaces that are not part of the present document. 

A stand-alone LMU has a serving-Node-B that provides signalling access to a controlling S-RNC. A stand-alone LMU 
also has a serving 3G-MSC, VLR and a subscription profile in an HLR. A stand-alone LMU always has a unique IMSI 
and supports all radio resource and mobility management functions of the UTRAN air interface that are necessary to 
support signalling. A stand-alone LMU shall support those connection management functions necessary to support LCS 



£75/ 



3GPP TS 25.305 version 3.3.0 Release 1 999 18 ETSI TS 1 25 305 V3.3.0 (2000-09) 

signalling transactions with the S-RNC and may support certain call control functions of to support signalling to an 
S-RNC using a circuit switched data connection. 

NOTE 3: A network operator may assign specific ranges of IMSI for its LMUs and may assign certain digits within 
the IMSI to indicate the associated S-RNC. Certain digits in the IMSI may also be used as a local 
identifier for an LMU within an S-RNC. 

To ensure that a Stand-alone LMU and its associated S-RNC can always access one another, an LMU may be homed 
(camped) on a particular cell site or group of cell sites belonging to one 3G-MSC. For any Stand-alone LMU with a 
subscription profile in an HLR, a special profile may be used to indicate the assigned supplementary services (e.g. the 
SMS-PP MT for data download via the SIM application toolkit, and barring of all incoming and possibly outgoing 
calls). An identifier in the HLR profile also distinguishes an LMU from a normal UE. All other data specific to an LMU 
is administered in the LMU and in its associated S-RNC. 

Associated LMU 

An associated LMU is accessed over the lub interface from an RNC. An associated LMU may make use of the radio 
apparatus and antennas of its associated Node-B. The LMU may be either a logically separate network element 
addressed using some pseudo-cell ID, or connected to or integrated in a Node-B. Signalling to an associated LMU is by 
means of messages routed through the controlling Node-B. 

An associated LMU may be separated from the Node-B, but still communicate with the S-RNC via the Node-B lub 
interface. The interface between the associated LMU and its Node-B is not part of the present document. 

NOTE 4: An associated LMU is not precluded from also communicating with other networks (e.g. GSM) through 
interfaces that are not part of the present document. 

Measurements 

The assistance measurements obtained by an LMU have are generic and are usable by more than one location method. 
These include: 

- Radio Interface Timing measurements: include Absolute Time Differences (ATDs) or Relative Time 
Differences (RTDs) of the signals transmitted by Node-B, where timing differences are measured relative to 
either some Absolute Time Difference (ATD) or the signals of another Node-B (RTD); 

- Inter-System Timing measurements: include the Absolute Time Difference (ATD) or Relative Time 
Difference between the UTRAN radio signals transmitted by a Node-B and an external system such as the GPS 
satellite navigation system or GSM. 

5.5.4 UE 

The UE interacts with the measurement co-ordination functions to transmit the needed signals for uplink based LCS 
measurements and to make measurements of downlink signals. The measurements to be made will be determined by the 
chosen location method. 

The UE may also contain LCS applications, or access an LCS application through communication with a network 
accessed by the UE or an application residing in the UE. This application may include the needed measurement and 
calculation functions to determine the UE's location with or without assistance of the UTRAN LCS entities. 

The UE may also, for example, contain an independent location function (e.g., GPS) and thus be able to report its 
location, independent of the UTRAN transmissions. The UE with an independent location function may also make use 
of information broadcast by the UTRAN that assists the function. 



Signalling protocols and interfaces 



NOTE: This clause describes the information flows, the detailed messages and protocols are described in other 

clauses. 
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6.1 LCS signalling between SRNC and IVISC/SGSN 

LCS signalling between SRNC and MSC/SGSN is handled through the lu interface, which is described in clause 6.6.3. 

6.2 SRNC signalling to a target UE 

SRNC signalling to a target UE is described in clause 6.6.4.1. 

6.3 Controlling RNC signalling to a standalone LIVIU 

Controlling RNC signalling to a standalone LMU is described in clause 6.6.4.2. 

6.4 Controlling RNC signalling to an associated LIVIU 

Controlling RNC signalling to an associated LMU is handled through the lub interface, which is described in clause 
6.6.1. 

6.5 RNC-to-RNC signalling for LCS support 

The RNC-to-RNC signalling for LCS support is handled through the lur interface, which is described in clause 6.6.2. 

6.6 Interfaces 

There are four interfaces through which the LCS entities communicate. These are the lu, the lur, lub and the Uu. 

NOTE: the interfaces between the Internal or External LCS applications and the 3G-MSC or 3G-SGSN are 
outside the scope of the present document. 

6.6.1 lu Interface 

The lu interface is used to communicate between the LCS functional entities in the Core Network and the LCS entities 
in the UTRAN. Further specification of the messages and operations for LCS across the lu interface may be found in 
reference [1]. 

6.6.2 lur Interface 

LCS operations at the lur interface are defined in [14]. 

The lur interface is used to communicate between the LCS functional entities associated with the serving RNC and 
other RNC in the UTRAN. The lur interface is also used to communicate between the serving RNC and the Internal 
LCS Applications in the UTRAN. The LCS entities associated with the serving RNC are responsible for co-ordinating 
and responding to location requests received from the LCS entities in the core network or Internal Clients. 

When communicating between the serving RNC and the UTRAN Internal LCS Applications (ILA), the messages and 
protocols are the same as those used over the lur interface. 

The lur interface is also used to communicate between the LCS Entities in the serving RNC and those in other RNC. 
The location method, for example, may require measurements by several LMU or Node-B, some of which may be 
associated with other RNC. Commands and responses from these LCS Entities are communicated over the lur interface. 
In some cases, the LCS Entities in the serving RNC may make use of entities associated with other RNC. For example, 
a calculating function (PCF) may be used in another RNC if the serving RNC is too busy or does not contain the 
function or database information required by the chosen location method. 

The lur interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the RNC. 
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lur shall be used for LCS signalling whenever it is available, even in the case when the RNCs connected to different 
3G-MSCS or 3G-SGSN. 

Within UTRAN, lur supports inter-RNC soft handover. Inter-RNC handover should also include LCS, meaning that 
whenever an inter-RNC soft handover occurs, lur should be able to support the functionality of the LCS entities in 
RNCs, including PCF, PRRM, PSMF, and LSOF. 

In addition, in case of SRNC relocation lur should support the relocation mechanism in order for DRNC to be able to 
handle the responsibility of SRNC in LCS process. That is, to transfer the PCF, PRRM, PSMF, and LSOF functionality 
from SRNC to DRNC. lur shall be used also to collect RTD and other LCS information from base stations under 
different RNCs that are not involved in handover. 

6.6.3 lub Interface 

LCS operations at the Tub interface are defined in [15]. 

The lub interface is used to communicate among the LCS entities associated with the serving RNC, the Node-B and the 
associated Location Measurement Units (LMU). 

This interface passes the request for measurements, the measurement results and requests for LCS related transmissions 
or other radio operations needed by the location method (e.g. broadcast of parameters needed for a UE based location 
method). 

The lub interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the Node-B or the LMU. 

6.6.3.1 Signalling between RNC and associated LMU 

Signalling exchanges between an RNC and a LMU under the control of that RNC will be specified in the NB AP 
protocol for associated LMUs. 

The protocol layers employed to enable signalling between the RNC and an associated LMU are defined in 25.430. The 
LMU signalling information elements are included directly in the NBAP protocol, defined in 25.433. 

6.6.4 Uu Interface 

LCS operations at the Uu interface are generally defined in [1]. This specification defines in more detail the procedures 
needed for messaging for each individual location method. 

The Uu interface is used to communicate among the LCS entities associated with the RNC, the UEs and the stand-alone 
Location Measurement Units (LMU) (the Uu interface is also used to communicate between the LCS entities in the core 
network and the UE. Those communications are beyond the scope of this specification). 

This interface may pass measurement requests and results to and from the UE or the stand-alone LMU. 

The Uu interface may also pass location requests from internal or external LCS Applications at the UE. 

NOTE: These requests may require the services of the LCS entities associated with the core network to 
authenticate clients and subscriber subscriptions to aspects of the LCS. 

The Uu interface may also be used for broadcast of information that may be used by the UE or stand-alone LMU for 
their LCS operations. This may, for example, include timing and code information about nearby Node-B transmissions 
that may assist the UE or LMU in making their measurements. 

The Uu interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the UE or the remote LMU. 

6.6.4.1 Signalling between S-RNC and Target UE 

LCS related signalling between an S-RNC and a target UE is supported by the RRC protocol. 

The location Request to UE signalling flow is generic for all UE based or assisted location methods (OTDOA and 
Network Assisted GPS). 
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Figure 6.1 : OTDOA /GPS Location IVIessage Flow 

1. The S-RNC determines possible assistance data and sends a MEASUREMENT CONTROL request to the UE. 

2. Provided that location request meets the privacy criteria, the UE performs the requested measurements. If the UE 
is able to calculate its own location, and this is requested, the UE computes a location estimate based on 
measurements. Any assistance data necessary to perform these operations will either be provided in the 
MEASUREMENT CONTROL request or be available from broadcast sources. The resulting measurements or 
location estimate are returned to UTRAN in a MEASUREMENT REPORT response. If the UE cannot fulfil the 
request, a MEASUREMENT CONTROL FAILURE message is returned. 



6.6.4.1.1 



Assistance Data Delivery to UE 



The assistance data signalling flow illustrated here is generic for UE based location methods, including OTDOA and 
Network Assisted GPS. Note that if the assistance data is sent as part of a broadcast message, then no assistance data 
acknowledgement is required. 



S-RNC 



UE 



1 . RRC Measurement Control 



Figure 6.2: OTDOA or GPS Assistance Data Delivery Flow 

1. The S-RNC determines assistance data and sends it in the RRC MEASUREMENT CONTROL message to the 
UE. 

6.6.4.1.2 Error Handling 

The error handling for signalling on the Uu interface is handled by the RRC protocol. 



6.6.4.1.3 



Broadcast of Assistance Data 



In the UE Based OTDOA or Network Assisted GPS methods, where the measurements and/or location calculation is 
done in the UE, assistance data may be broadcast to the UE. 

The assistance data to be broadcast for UE Based OTDOA contains the Relative Time Difference (RTD) values (e.g. in 
case of a non-synchronised network) and base station co-ordinates. In addition, the broadcast data may contain other 
information to simplify the OTDOA measurements. The length of the message depends on how many neighbours are 
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included in the assistance data. Part of the broadcast message (e.g. the serving and neighbour base station geographic 
co-ordinates) may be ciphered. 

The assistance data to be broadcast for assisted GPS contains DGPS corrections, ephemeris and clock corrections, as 
well as almanac and other data. Part of the broadcast message may be ciphered. 

The broadcast channel that is used for the OTDOA and GPS assistance data makes use of the common UTRAN 
broadcast service. 

6.6.4.1 .4 Signalling Flow for Assistance Data Broadcast Using the Common UTRAN 

Broadcast Service 

The assistance data broadcast to UEs can be signalled via the RRC Measurement Control message as shown in 
subclause 6.6.4.2 or it can be broadcast by the UTRAN within the system information. 



S-RNC 



UE 



SYSTEM INFORMATION 



6.6.4.1.5 



Figure 6.3: Broadcast of system information 



LCS Assistance Data Ciphering 



To allow control of access to the assistance data, parts of the broadcast assistance data may be ciphered. Ciphering is 
done with a specific ciphering key delivered by the core network for this purpose. The management of the key is 
described in the System Aspects Stage 2 ([!]). 



6.6.4.1.6 



LCS Assistance Data Ciphering Algorithm 



The algorithm used for ciphering the LCS assistance data is the standard 56-bit Data Encryption Standard (DBS) 
algorithm. 

The deciphering of broadcast assistance messages is done in the UEs. The deciphering will utiUze the deciphering keys 
delivered during the location update request. 

The RNC ciphers the parts of the LCS Broadcast Data message to be protected using the 56-bit DES algorithm and a 
ciphering keys (56 bits) and Ciphering Serial Number (16 bits) for the broadcast location area. 

The ciphered part is variable in length with one bit resolution. By using the LCS Broadcast Data message header, the 
UEs can determine what part of message is ciphered. 

Inputs to the 56-bit DES algorithm are the following: 

56-bit key K (deciphering key); 

16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (Initialization Vector); 

- plain-text bits (the ciphered part of broadcast message). 

The ciphering process is illustrated in the following diagram. Ciphering is done by producing a mask bit stream which 
is then "XORed" bit-by-bit to the plain-text data to obtain the cipher-text data. First, the Initialization Vector (IV) is 
concatenated with 0-bits in order to achieve a 64-bit block Ii. This block is then encrypted by the DES algorithm using 
the key K. Output is a 64-bit block I2. This constitutes the first 64 bits of the mask bit stream. If the message is longer 
than 64 bits, then more bits are needed. These are produced by encrypting I2 again by the DES algorithm using the key 
K. The output is a 64-bit block I3. This is the next 64 bits of the mask bit stream. This iteration is continued until enough 
bits are produced. The unnecessary bits from the last 64-bit block Ij are discarded. The figure below illustrates the first 
two mask bit generations and the two ciphered 64-bit blocks. 
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1st 64-bit block of the broadcast message to be ciphered 



1st 64-bit ciphered blocl< to the broadcast message 



1^' DES 



i I. 



2nd Mask Bit Stream (64 bits) 



2nd 64-bit block of the broadcast message to be ciphered 



2nd 64-bit ciphered block to the broadcast message 



> 



Figure 6.4: Data Assistance Ciphering Algorithm 



■^.. XOR 



Deciphering is done similarly. The same mask bit stream is produced and these are XORed, bit-by-bit, to the cipher-text 
data bits. The result will be the plain-text data. 

6.6.4.2 Signalling between RNC and stand-alone LMU 

The use of stand-alone LMUs is FFS. If it is decided to have stand-alone LMUs in the standard, the signalling will be 
performed with the new protocol LLP. If no need is seen for the stand-alone LMUs the LLP protocol will not be defined 
and it will be removed from 25.305. 

The following figures illustrate the protocol layers used to support signalling between an RNC and a Stand- Alone LMU 
over the Uu interface. 
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6.6.4.2.1 



Signalling using a signalling bearer 
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Figure 6.5: Signalling between an RNC and a Stand-Alone LMU using a signalling bearer 



6.6.4.2.2 



Signalling using a radio bearer 
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Figure 6.6: Signalling between an RNC and a Stand-Alone LMU using a radio bearer 



7 General UMTS location procedures 

7.1 General network location procedures 

The General network location procedure in UTRAN start with a request over lu from the CN. UTRAN then determines 
the UE location by selecting a suitable location method. UTRAN then responds to the request with the estimated 
location and possible an associated accuracy. 
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7.2 Common procedures to support access to a LMU 

NOTE: 7.2 and 7.3 will be considered if stand-alone LMUs are included. 

7.3 Common control procedures for LMUs 

7.3.1 Reset procedure 

7.3.2 Status query procedure 

7.3.3 Status update procedure 

7.4 Common procedures supporting LCS interaction between 
RNCs 

In the case that LCS information is needed from an associated LMU in a Node B that is not controlled by the SRNC 
information transfer is needed on the lur interface. This information is the same information that is signalled between an 
associated LMU and the corresponding controlling RNC in the case when lur support is not needed. 

The SRNC requests the information it requires (e.g. GPS timing of cell measurements) from the controlling RNC of the 
Node B which has the associated LMU. The controlling RNC in turn requests the information from the Node B and 
upon success returns the results to the SRNC. 

Similarly when the SRNC needs a Node B measurement on a UE when that Node B is not controlled by that SRNC 
there needs to be support on the lur. One example is the RTT measurement. 

Other information that may need to be signalled over the lur includes LMU parameters (geographical position, covered 
cells etc.). NOTE: Confirmation or FS is needed by R3 experts. 

NOTE: LCS during SRNS relocation is unclear. 

7.5 Exception procedures 

7.5.1 Procedures in the SRNC 

When a location attempt fails due to failure of a position method itself (e.g. due to inaccurate or insufficient position 
measurements and related data) and the SRNC is unable to instigate another positioning attempt (e.g. due to a 
requirement on response time), the SRNC may return a Location response over the lu interface containing a less 
accurate location estimate. If a less accurate estimate is not available or will not meet the accuracy requirement, the 
SRNC may instead return a Location response message containing no location estimate and indicating the cause of 
failure. 

NOTE: Need to check that lu has enough flexibility 

When a location attempt is interrupted by some other unrecoverable error event inside the SRNC, the SRNC shall 
immediately terminate the location attempt and return a Location Response message containing the reason for the 
location attempt cancellation. In that case, any dialogue previously opened with an LMU for the purpose of instigating 
position measurements for the UE being located may also be aborted by the SMLC. 

7.5.2 Procedures in a LIVIU 

An LMU shall return an error indication to its controlling RNC when location measurements previously ordered by the 
RNC cannot be provided due to any error condition. 
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7.5.3 Procedures in the target UE 



A target UE shall terminate any positioning procedure or the transfer of RRC positioning assistance data without 
sending any response to the SRNC if any LCS RRC message is received from the SRNC that starts some other RRC 
management procedure. The new RRC procedure shall then be executed by the UE. 

7.6 Radio interface timing procedures 

The Radio Interface Timing determination system consists of functions in LMUs and in the SRNC. The system runs 
continuously offering cell timing information for mobile station location. 

7.6.1 LIVIU Functions 

The Radio Interface Timing functionality in the LMU should be capable of performing the following functions: 

The LMU performs necessary air interface measurements from signals transmitted by Node Bs 

If the LMU contains a common reference clock, e.g. GPS TOW, it time stamps reception of Node B signals. 

If there is no reference clock available, the LMU may make Relative Time Difference measurements, i.e. 
measures the time difference between arrival of SFNs 

The LMU may perform some processing of measurements, like averaging and filtering, using parameters 
delivered to it, or in their absence using default settings 

7.6.2 SRNC Functions 

The SRNC must be capable of performing the following functions related to Radio Interface Timing determination: 

The SRNC sends to LMUs requests for Radio Interface Timing measurement information. 

The SRNC will communicate regularly with LMUs; thus, the SRNC can monitor operation of LMUs. If a LMU 
fails to send Radio Interface Timing information, the SRNC shall try to restart the LMU, and if this restarting 
fails, the SRNC shall inform O&M system. SRNC can use also diagnostics messages to query the status of 
LMUs. 

The SRNC receives Radio Interface Timing measurement results from LMUs. 

The SRNC stores or queries extra information required for Node B synchronization determination, like base 
station and LMU coordinates. Node B identity information. 

The SRNC determines synchronization differences between different downlink signals using LMU 
measurements and other information. 

Synchronization information is delivered for UE location purposes. 

7.6.3 LIVIU-SRNC Interactions 

The request for Radio Interface Timing measurement information from the SRNC to a LMU contains the following 
parameters: 

Measurement type. This indicates whether the SRNC wants the LMU to perform Absolute Time Difference 
(ATD) (e.g. GPS time stamp of signal) or Relative Time Difference (RTD) measurements. 

Measurement result reporting frequency. This indicates how often the LMU should send Radio Interface Timing 
measurement results. 

Measurement duration. This indicates how long the LMU should make measurements and report results. 

Instructions about filtering of raw measurement data. 
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Instructions about Primary CPICH signals to be measured. The LMU unit can measure autonomously a certain 
number of most strongly received signals. Another possibility is that the SRNC tells which Node B signals it 
should measure. 

In the RTD case, which common Primary CPICH the LMU should use as a reference in the measurements. 

Instruction of how the measurement quality should be reported. 

The Radio Interface Timing measurement response from a LMU to the SRNC contains: 

Identity of the Node B at which the asssociated LMU is residing 

Primary CPICH info of the measured signals. 

If the LMU can perform ATD measurements, and it is requested to do them, the ATD measurements of the 
requested CPICH signals is returned. 

If the LMU can perform RTD measurements, and it is requested to do them, the RTD measurements of the 
requested CPICH signals is returned. 

The SFN of the last frame measured, for each measurement. 

The quality of each measurement, according to the requested quality type 



8 



Cell ID based location method 



In the Cell ID based method, the S-RNC determines the identification of the cell providing coverage for the target UE. 
This subsection outlines the procedures for this location method. Sub-section 8.1 provides procedures for the 
determination of the cell ID depending on the operational status of the target UE. Sub-section 8.2 discusses the relation 
between the LCS location service and the Support of Localised Service Area (SoLSA) feature. Sub-section 8.3 provides 
a procedure for the mapping of the Cell ID to a corresponding Service Area Identifier (S AJ) to be returned to the LCS 
application in the core network. The general flow to determine the cell ID is shown in figure 8.L 
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Figure 8.1 : Cell ID Based Method 



8.1 



Cell ID determination 



In order for the S-RNC to determine the cell ID when an LCS request is received, additional operations may be needed 
depending on the operational status of the UE. 
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Figure 8.1 illustrates the procedure for the cell ID based location method when the UE is in different RRC states. When 
the LCS request is received from the core network the S-RNC checks the state of the target UE. If the UE is in a state 
where the cell ID is available, the target cell ID is chosen as the basis for the UE location. In states where the cell ID is 
not available, the UE is paged, so that S-RNC can establish the cell with which the target UE is associated. In order to 
improve the accuracy of the LCS response the S-RNC may also request RTT or RX Timing Deviation measurements 
from the Node B or LMU associated with the cell ID. The S-RNC may also map the cell ID to a corresponding Service 
Area Identifier (SAI) to match the service coverage information available in the core network. 

The cell ID based method shall determine the location of the UE regardless of the RRC state, including URA_PCH, 
Cell_PCH, Cell_DCH, Cell_FACH, cell reselection, inter-system modes, as well as an idle mode. 

8.1.1 UE Cell ID is not known 

For UE for which the cell ID is not known at the time the LCS request is received at the S-RNC, the UE may be paged 
to locate its current cell ID. If the UE is in an idle mode and there is a need for it to be paged, then the paging may be 
initiated either by the core network or by the S-RNC in the UTRAN access network. For example, the UE can be forced 
to perform a transition to a Cell_FACH state to define the cell ID of its current cell. 

If the UE is in an idle mode, Cell_PCH state or in any other state when there is a need to page for the UE to obtain the 
cell ID, the Core Network may initiate paging, authentication and ciphering, as specified in TS 23.171. 

Alternatively, the cell ID may be determined as the one that was used during the last active connection to the UE. This 
determination should be accompanied by the time-of-day of the last connection in the cell. 

8.1.2 UECell ID is known 

8.1 .2.1 UE not in Soft handover 

The cell ID may be determined as the cell that is providing an active connection for the UE at the time of receiving the 
LCS request at the S-RNC. 

8.1 .2.2 UE in Soft handover 

In order for the S-RNC to provide the geographical co-ordinates of a target UE in soft handover, the S-RNC combines 
the information about all cells associated with the UE. 

In soft handover, the UE may have several signal branches connected to different cells, reporting different cell IDs. A 
reference cell ID may be determined by the S-RNC based on the coverage area of each cell. The reference cell ID may 
be selected based on one or more of the following principles: 

the cell ID may be selected based on the parameters defining the quality of the received signal branches. That is, 
the cell ID with the best quality signal branch is selected as the reference cell ID; 

the cell ID may be selected that was used during connection set-up between the UE and the serving Node B; 

the cell ID of the cell most recently associated with the UE may be selected;; 

the cell ID of the latest "new" cell that the UE has started to receive, but has not yet been handed over to may be 
selected; 

the cell ID may be selected as the cell to which UE has the shortest distance (to the Node-B site); 

the cell ID may be selected as the cell that provides an active connection for the UE at the time of receiving 
theLCS request at the S-RNC. 

The selection may also be based on measurements of Round Trip Time, power levels and received signal strengths in 
UE and related Node B or LMU. 

Other relevant mechanisms such as Idle Period Downlink, (IPDL) or Site Selection Diversity Transmit power control 
(SSDT) should also be taken into account when applying the cell ID selection procedure for UE in a soft handover 
mode. 
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8.2 Localised Service Area 

The Support of Localised Service Area (SoLSA) feature is quite close to the location service in principle, but SoLSA is 
based, for example, on radio network cell coverage and cell configuration. SoLSA has been standardised in GSM and is 
being developed for UTRAN. Some SoLSA service features like Exclusive Access and LSA only Access may be less 
applicable in UTRAN due to the 1 frequency reuse. 

It should be noted that the Service Area concept described in this specification is different from the Localised Service 
Area concept defined for SoLSA. 

8.3 IVIapping the Cell ID to Geographic Co-ordinates or a 
Service Area 

A UTRAN cell ID should be mapped to geographical coordinates or a Service Area Identifier (SAI) before being sent 
from UTRAN to the core network. The Service Area Identifier may include one or several cells. The mapping may be 
accomplished either in the S-RNC, in a Network Management System (NMS, including Network Management Unit, 
NEMU) or by co-operation of various access network elements. 

The core network may request the geographical co-ordinates or the SAI, or both for the target UE. The SAI may be used 
for routing of corresponding Emergency calls, or for CAMEL services to correspond to the usage of Cell ID in the core 
network of GSM. However, the MSC shall not send the Service Area Identity to GMLC. 

Although the mapping of the cell(s) associated with the target UE into geographical co-ordinates by the S-RNC is not 
standardised, the response to the core network location request with geographical co-ordinates shall be as defined in TS 

23.032. 

It should be noted that the Service Area concept is different from the Localised Service Area concept used for SoLSA 
services. 

In order to determine a cell coverage estimate and to map it to the geographical coordinates or Service Area parameter 
Identity, the S-RNC may use parameters such as the best reference signal. Round Trip Time (RTT) in FDD [17] or Rx 
Timing Deviation [18] and knowledge of the UE timing advance in TDD, as well as antenna beam direction parameters. 

Alternatively, the service area coverage of a cell may be determined by using a reference signal power budget. Based on 
the reference signal power budget it is possible to obtain, for example, the base station transmitted power, isotropic path 
loss, coverage threshold at coverage area border for a given location probability, and a cell radius for an indoor and 
outdoor coverage. 

The S-RNC may use a reference signal link budget based cell radius estimate, in conjunction with the cell identifier, to 
make a coverage estimation for the cell(s) related to the target UE. 

Additionally, the S-RNC may compare the received power levels with the power budget, whereby more accurate 
information of the location of the UE may be provided. 

Also, the interaction between neighbouring cell coverage areas may be used to determine a more exact location of the 
UE. 
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OTDOA location method 



The primary standard OTDOA measurement is the "SFN-SFN observed time difference" observed at the UE (see [17 
and [18]. These measurements, together with other information concerning the surveyed geographic location of the 
transmitters and the relative time difference (RTD) of the actual transmissions of the downlink signals may be used to 
calculate an estimate of the location of the UE. Each OTDOA measurement for a pair of downlink transmissions 
describes a line of constant difference (a hyperbola (see note 1)) along which the UE may be located. The UE's location 
is determined by the intersection of these lines for at least two pairs of base stations. The accuracy of the location 
estimates made with this technique depends on the precision of the timing measurements, the relative location of the 
base stations involved (see note 2), and is also subject to the effects of multipath radio propagation. This is illustrated in 
the figure 9.1. 

NOTE 1 : This is really a figure in three dimensions, a hyperboloid. For convenience here, this will be simplified to 
the hyperbola representing the intersection of this surface with the surface of the earth. For location 
service in three dimensions the hyperboloid must be considered. 

NOTE 2: The geometry of the base station locations may affect the accuracy of the location estimate. The best 

results are when the base stations equally surround the UE. If they do not, there is a reduction in accuracy, 
which is sometimes termed the Geometric Dilution of Position (GDP). 

The primary OTDOA measurements (made by the UE) are sent to the Position Calculation Function (PCF) in the 
serving RNC. These measures are sent via signalling over the Uu, lub (and lur) interfaces between the UE and the 
SRNC (PCF). The calculation function makes use of the measurements, the known locations of the transmitter sites and 
the relative time difference of the transmissions to estimate the UE's location. 
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Figure 9.1 : OTDOA Location Method 

The OTDOA method may be operated in two modes: UE assisted OTDOA and UE based OTDOA. The two modes 
differ in where the actual location calculation is carried out. In the UE assisted mode, the UE measures the difference in 
time of arrival of several cells and signals the measurement results to the network, where a network element (the 
Position Calculation Function (PCF)) carries out the location calculation. In the UE based mode, the UE makes the 
measurements and also carries out the location calculation, and thus requires additional information (such as the 
location of the measured base stations) that is required for the location calculation. The signalling requirements for the 
two OTDOA modes are described in a later subclause. As the LCS involves measurements, there is always uncertainty 
in the results. Physical conditions, errors and resolution limits in the apparatus all contribute to uncertainty. To 
minimise the uncertainty in the LCS result, it is important that as many measurements of TDOA (and assistance data as 
RTT in FDD and Rx Timing Deviation in TDD) as are possible for a UE are provided to the PCF. Thus it is important 
that the standard method for LCS not be restricted to rely on a single measure. The UE thus provides SFN-SFN 
observed time difference measurements for as many cells as it can receive. The cellsto be measured shall include those 
in the "cell reselection and monitoring set" and those in the "cell selection set". 
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In order to support the OTDOA method, the locations of the UTRAN transmitters needs to be accurately known by the 
calculation function (PCF). This information may be measured by appropriate conventional surveying techniques (see 
note 3). The surveyed location should be the electrical centre of the transmitting antenna (and not the location of the 
radio equipment building). The use of antenna diversity, beamforming or beam steering techniques may cause the 
effective antenna location to change with time and this information will need to be communicated to the PCF to assist 
with its calculations. The methods of measuring the location of the UTRAN transmitters are outside the scope of the 
present document. 



NOTE 3: These surveying methods may, for example, make use of a GPS receiver. 



In order to support the OTDOA method, the relative time difference (RTD) of the downlink transmissions must also be 
known by the calculation function (PCF). If the UTRAN transmitters are unsynchronised, the RTD will change over 
time as the individual clocks drift. Thus, measurements of RTD may need to be made regularly and the calculation 
function updated appropriately. The measurement of the RTD is outside the scope of the present document (see note 4). 

NOTE 4: One convenient method is to make use of an LMU at a fixed location. This unit measures the observed 
time differences of all the local transmitters and reports these to the PCF. These measures may then be 
converted (translated) into the actual (absolute) relative time difference for each of the transmitters by 
making use of the known location of the LMU and the transmitters. 

In some conditions a sufficient number of cells may not be available for measure at the UE. This may occur, for 
example, if the UE is located quite close to the UTRAN transmitter and its receiver is blocked by the strong local 
transmissions. This is referred to as the "hearability" problem. 



9.1 Use of Idle Periods (FDD only) 



For realising location based services the support of physical layer is a prerequisite, so that the measurements required 
for the terminal location calculation can be carried out. In UTRAN there are several factors that must be taken into 
account while considering the physical layer procedures related to location services: 

- hearability: a basic consequence of a CDMA radio system is that a terminal near its serving base station cannot 
hear other base stations on the same frequency. In order to calculate terminal location the terminal should be able 
to receive at least three base stations. To facilitate this some special means are required; 

asynchronous network causes significant uncertainty to the time-difference-of-arrival (TDOA) measurements. 
To compensate for the effects of this, the relative time difference (the synchronicity) between base station 
transmissions must be measured, and used for correcting TDOA measurement; 

capacity loss: signalling related to location calculation may take capacity from other services. This capacity loss 
should be minimised. 

Based on the results of the work done in ARIB SWG2/ST9 (see reference [21]) a solution for the above mentioned 
hearability problem is the IPDL (Idle Period DownLink) method. In this method each base station ceases its 
transmission for short periods of time (idle periods). During an idle period of a base station, terminals within the cell 
can measure other base stations and the hearability problem is reduced. Also, during idle periods the real time 
difference measurements can be carried out. Because the IPDL method is based on forward link (downlink) the location 
service can be provided efficiently to a large number of terminals simultaneously. 

The specification and operation of the IPDL technique are provided in the following subclause. 

9.1 .1 Operation and specification of idle periods 

The operation and specification of idle periods can be found in TS 25.214 (reference [16]). 

9.2 Relative Time Difference (RTD) 

In order to calculate the estimate of the location of the UE, the calculation function needs to know: 
the OTDOA measurements; 
the surveyed geographic locations of the base stations that have had their signals measured; and 
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the actual relative time difference between the transmissions of the base stations at the time the OTDOA 
measurements were made. 

The accuracy of each of these measurements contributes to the overall accuracy of the location estimate. The 
measurement of the RTD is described in the following. 

There are several approaches to determining the RTD. One is to synchronise the transmissions of the base stations. In 
this technique the RTD are known constant values (see NOTE) that may be entered in the database and used by the 
calculation function when making a location estimate. The synchronisation must be done to a level of accuracy of the 
order of tens of nanoseconds (as 10 nanoseconds uncertainty contributes 3 metres error in the location estimate). Drift 
and jitter in the synchronisation timing must also be well controlled as these also contribute uncertainty in the location 
estimate. Synchronisation to this level of accuracy is currently only readily available through satellite based time- 
transfer techniques. Generally in the TDD operating mode, the base stations are synchronised. 

NOTE: The transmission times may all be aligned to a common reference (such as UTC) in which case all RTD 
have a common value. However, in a more general case the transmissions may have a fixed offset with 
reference to UTC, and thus the RTD values are non-zero and may be stored in the database for use by the 
calculation function. 

Alternatively (typically in FDD mode), the base stations may be left to free run within some constraint of maximum 
frequency error. In this scenario, the RTD will change (slowly) with time. The rate of change will depend on the 
frequency difference and jitter between base stations. If, for example, the maximum frequency difference between two 
base stations is +10'^, then the start of transmission of a 10 millisecond code sequence will drift through a cycle in about 
1 390 hours (or 57 days). With this relatively slow rate of drift the RTD can be measured by fixed units at known 
locations (these are LMUs, Location Measurement Units) and stored in the database for use by the calculation function. 
The jitter and drift of the individual oscillators in each base station may cause the change of timing to slow, remain 
constant or reverse direction over time. Ongoing measurements of the RTD may be made to assure the most current 
values are available for the calculation function. The RTD measurement units may be co-located with the base stations 
or installed at other convenient locations in the UTRAN coverage area, and report their results through the UTRAN 
signalling channels. 



9.3 Time of Day (ToD) 



If there are frequency drifts between the (unsynchronised) Node Bs, as noted in the previous subclause, the OTDOA 
measurements must be reported together with the time-of-day they were made (timestamp). This is necessary so that the 
appropriate value of the RTD may be used by the calculation function. 

In order to assure less than a 20 nanosecond uncertainty in the RTD value, the time of day must be known to better than 
10 seconds (if the maximum frequency difference between the base stations is +10"'). The method by which the ToD is 
measured is the system the frame number, which provides a 10 millisecond resolution and can be unambiguous up to 
40.95 seconds.. 



9.4 Base Station Synchronisation 



It is preferable that the location methods do not require the base station network to be synchronised. The needed level of 
synchronisation accuracy for LCS is not by any means straightforward to achieve. The necessary information of 
Relative Time Differences (RTD) between base stations can be measured by dedicated units (LMU, Location 
Measurement Unit) and distributed in the network (e.g. as broadcast information). Also, the measurements of RTD may 
benefit from the Idle Period DownLink (IPDL) option. 

In the TDD operating mode the base stations will typically be synchronised and this may be of assistance to the LCS 
technique. 

9.5 OTDOA-IPDL and OTDOA IVIodes 

There are two modes of operation for the OTDOA-IPDL and OTDOA methods. In the UE assisted mode, the UE 
measures the difference in time of arrival of several cells and signals the measurement results to the network, where a 
network element (the Position Calculation Function (PCF)) carries out the location calculation. In the UE based mode, 
the UE makes the measurements and also carries out the location calculation, and thus requires additional information 
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(such as the location of the measured base stations) that is required for the location calculation. This information is 
provided by the Location System Information Function (LSIF). 

Table 9.1 lists the required information for both UE assisted and UE based modes. The required information can be 
signalled to the UE either in a broadcast channel or partly also as dedicated signalling. 

Table 9.1 : Information required for UE assisted and UE based OTDOA- IPDL and OTDOA in the 
UTRAN (LSIF) to UE direction ('Yes' = information required, 'No' = Information not required) 



Information 


UE assisted 


UE based 


Intra frequency Cell Info (neighbour list). 


Yes 


Yes 


Ciphering information for LCS (see note) 


No 


Yes 


IVIeasurement control information (idle period locations) 


Yes 


Yes 


Sectorisation of the neighbouring cells 


No 


Yes 


IVIeasured RTD values for Cells mentioned at Intra 
frequency Cell Info 


No 


Yes 


RTD accuracy 


No 


Yes 


Measured roundtrip delay for primary serving cell 


No 


Yes 


Geographical location of the primary serving cell. 


No 


Yes 


Relative neighbour cell geographical location 


No 


Yes 


Accuracy range of the geographic location values 


No 


Yes 


NOTE: The idea behind LCS specific ciphering information is e.g. that the operator 
can sell information that the UE needs for calculating its location. For 
reference in the GSM world see [3]. 



The information required from UE to UTRAN (PSMF/PCF) is listed in table 9.2. 

Table 9.2: Information required for UE assisted and UE based OTDOA- IPDL and OTDOA 

in the UE to UTRAN (PSMF/PCF) direction 



Information 


UE assisted 


UE based 


OTDOA measurement results 


Yes 


No 


OTDOA measurement accuracy 


Yes 


No 


UE geographical location 


No 


Yes 


Location accuracy indicator (based on the signalled and 
measurement accuracies) 


No 


Yes 



9.6 OTDOA network location procedures 

The following diagram illustrates the operations for the OTDOA-LCS when the request for location information is 
initiated by an LCS application signalled from the Core Network. As these operations are internal to the RNC, this 
diagram is to illustrate information flow and implementations may use alternate arrangements. 

This illustration only includes the information flow related to LCS operations and does not indicate other operations that 
may be required, for example, to establish a signalling connection between the UE and the SRNC. Also not illustrated is 
the signalling used to initiate the location service request (from the Location Client Function) from the Core Network or 
a UE based application. 
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Figure 9.2: OTDOA Signalling Operations 

1 . The operation begins with an authenticated request for location information about a UE from an application in 
the core network being received at the LSCF. The LSCF acts as interface between the Core Network and the 
LCS entities in the UTRAN. 

2. The LSCF considers the request and the capabilities of the UE and the network and forwards the request to the 
appropriate PRCF in the Serving RNC. 

3. The PRCF requests from the UE the measurement of the OTDOA for the signals in the active and 
neighbourhood sets. These measurements may be made while the UE is in the idle state or while it is connected. 

4. If it is considered advantageous to do so, the PRCF requests the UE TX-Rx timing difference information from 
the UE. 

5. The UE returns the OTDOA measures to the PRCF. The PRCF receives the OTDOA information and co- 
ordinates obtaining other information to support the calculation request (not illustrated). 

6. The UE returns the UE TX-Rx timing difference information to the PRCF, together with a time stamp of when 
the value was obtained. 

7. If there are insufficient OTDOA measures, or it is otherwise considered advantageous to do so, the PRCF 
requests the RTT measure for the UE from the PSMF in the serving Node-B. 

8. The PRCF requests the RTD measures for the associated transmitters from the LSOF (database). These may be 
stored locally if they are constant over time, otherwise they must be updated to represent the RTD timing at the 
time-of-day the OTDOA measurements were made. 

9. The PSMF in the Node-B returns the RTT measures to the PRCF if they were requested. 

10. The LSOF returns the RTD information to the PRCF. 

11. The PRCF passes the OTDOA, RTD and, if necessary, RTT information to the PCF and requests a location 
calculation. The calculation may include a co-ordinate transformation to the geographic system requested by the 
application. 
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12. The PCF returns the location estimate to the PRCF. This estimate includes the location, the estimated accuracy 
of the results and the time of day of the estimate. 

13. The PRCF passes the location estimate to the LSCF. 

14. The LSCF passes the location estimate to the Core Network. 



10 



Network assisted GPS location method 



When GPS is designed to inter-work with the UTRAN, the network assists the UE GPS receiver to improve the 
performance in several respects. These performance improvements will: 

- reduce the UE GPS start-up and acquisition times; the search window can be limited and the measurements sped 
up significantly; 

increase the UE GPS sensitivity; location assistance messages are obtained via UTRAN so the UE GPS can 
operate also in low SNR situations when it is unable to demodulate UE GPS signals; 

allow the UE to consume less handset power than with stand-alone GPS ; this is due to rapid start-up times as the 
GPS can be in idle mode when it is not needed. 

The Network assisted GPS methods rely on signalling between possibly reduced complexity UE GPS receivers and a 
continuously operating GPS reference receiver network which has clear sky visibility of the same GPS constellation as 
the assisted UEs. GPS reference receivers may be connected to the UTRAN to enable derivation of UE assistance 
signals. 
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Figure 10.1 : Network assisted GPS methods 
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10.1 Timing calibration 

Timing calibration is achieved by using UE or UTRAN GPS timing measurements as specified in [17]. 

10.2 Timing assistance 

The UTRAN may derive the estimated UE location using UTRAN (eg. Cell-ID or IPDL) parameters and may use this 
information, in conjunction with satellite specific ephemeris data received from the GPS reference receiver network, to 
derive the estimated times of arrival (code phases) for equivalent GPS satellite signals received by the UE-based GPS 
receiver functionality. The estimated code phase data may be conveyed, together with Tutran-gps (as specified in [17] 
and [18]), from the UTRAN to the UE using higher layer signalling. The estimated code phase data value is uncertain to 
a degree depending on the accuracy of the UTRAN timing calibration and initial location determination methods used. 

10.3 Data assistance 

The UE may receive GPS information through the UTRAN air interface, using higher layer signalling. 

When the UE is unable to detect a sufficient number of satellites, the assisted GPS method can be combined with other 
location methods. Altitude assistance can compensate for one satellite measurement. 

The assistance data signalled to the UE may include all information listed below or a selected subset: 

data assisting the measurements; e.g. reference time, visible satellite list, satellite signal Doppler, code phase, 
Doppler and code phase search windows. This data can be valid for a few minutes (e.g., less than 5 minutes) or 
longer depending on the code phase and Doppler search window size that can be accommodated by the UE; 

data providing means for location calculation; e.g. reference time, reference location, satellite ephemeris, clock 
corrections. Satellite ephemeris and clock corrections data can be used for up to six hours. 

NOTE: Certain types of GPS Assistance data may be derived, wholly or partially, from other types of GPS 
Assistance data. 

If DGPS is utilised, then differential corrections may also be transmitted. If Selective Availability is turned off, these 
corrections can be valid for a few minutes or more. The DGPS data is valid for a large geographical area, so one 
centrally located reference receiver can be used to service this large region. 

10.4 UE search 

Provided that timing and/or data assistance is available in the UE they should be applied in the GPS signal 
searchprocedure. UE search procedure involves a three-dimensional search for a satellite PRN (pseudorandom) code, 
time of arrival of a signal and the associated carrier Doppler. 

"Modulation wipe-off" is defined here to mean a removal of the GPS navigation data bit modulation to GPS signals 
received at the UE, through the application of UTRAN timing and data assistance provided from the UTRAN to the UE. 
This process allows the UE to coherently integrate received GPS signals beyond 1 data bit period (i.e., 20 milliseconds). 



10.5 Location determination 

Computation of the location fix can either be performed in the network infrastructure (UE-assisted) or in the UE 
(UE-based). 

There are two types of network assisted GPS methods, namely UE-based and UE-assisted, which differ according to 
where the actual location calculation is carried out. 
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10.5.1 UE-based method 

The UE-based method maintains a full GPS receiver functionality in the UE, and the location calculation is carried out 
by the UE, thus allowing stand-alone location fixes. 

If the location was requested by an application in the network, then the calculated location is signalled to the proper 
network element. 

The following information may be signalled from the UTRAN (LSIF) to the UE: 

number of satellites for which assistance is provided; 

- reference time for GPS (Tutran-gps) (specified in [17] and [18]); 
3-d reference location (specified in [17]); 

ionospheric corrections; 

satellite ID for identifying the satellites for which the assistance is provided; 

ephemeris and clock corrections to accurately model the orbit of the particular satellite and information when 
this becomes valid; 

- UTC offset; 
DGPS corrections; 
almanac data; 

- real-time integrity (e.g., a list of unusable satellites). 

The following information may be signalled from the UE to the UTRAN (LSIF): 

reference time for GPS (specified in [17] and [18]); 

serving cell information; 

Latitude/Longitude/ Altitude/Error ellipse; 

velocity estimate of the UE; 

satellite ID for which the measurement data is valid; 

Whole/Fractional chips for information about the code-phase measurements; 

C/No of the received signal from the particular satellite used in the measurements; 

doppler frequency measured by the UE for the particular satellite signal; 

pseudorange RMS error; 

- multipath indicator. 

10.5.2 UE-assisted method 

In the UE-assisted method, the UE employs a reduced complexity GPS receiver functionality. This carries out the 
pseudorange (code phase) measurements. These are signalled, using higher layer signalling, to the specific network 
element that estimates the location of the UE and carries out the remaining GPS operations. In this method, accurately 
timed code phase signalling (as specified in [17] and [18]) is required on the downlink. If DGPS is performed in the UE, 
then differential corrections must be signalled to it. On the other hand, DGPS corrections can be applied to the final 
result in the network to improve the location accuracy without extra signalling to the UE. 

The following information may be signalled from the UTRAN (LSIF) to the UE: 

number of satellites for which assistance is provided; 

reference time for GPS (Tutran-gps) (specified in [17] and [18]); 

satellite ID for identifying the satellites for which the assistance is provided; 

doppler (0* order term); 
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Doppler Search Window width; 

doppler ( 1 ^' order term) ; 

- code phase; 

code phase centre and Search Window width; 

ephemeris; 

azimuth; 

elevation. 

The following information may be signalled from the UE to the UTRAN (LSIF): 

reference time for GPS (Tuegps) (specified in [17] and [18]); 

- number of Pseudoranges; 

- SVID; 

- satelUte C/No; 
doppler; 

satellite Code Phase; 
multipath indicator; 

- pseudorange RMS Error. 

Additional parameters, such as round trip time (RTT) in FDD or Rx Timing Deviation in TDD, UE receiving 
transmitting time (UE RxTx), SFN-SFN observed time difference and CPICH Ec/No, may be used to improve the 
performance of UE-assisted GPS. All the additional parameters are defined in [17] and [18] and can be made available 
through RRC signalling. Furthermore, to those UE technologies requiring externally provided sensitivity and time 
aiding data, some navigation bits may be sent from UTRAN to UE for sensitivity assistance and time recovery. 

1 1 Position calculation functionality 

NOTE: The functionality of the PCF is described in more detail in an informative annex FES. 



12 Information storage 



NOTE This clause just outlines the information that may need to be stored in the UTRAN LCS elements (U- 
LCF, U-PSCF,U-LSCF, UE, etc) that may need to be standardised (if any). 
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Annex A (informative): 
Definitions and Terms 



This annex provides definitions and terms for the general LCS. Not all of these are applicable to the UTRAN 
environment. 

CAMEL: CAMEL is a network functionality, which provides the mechanisms of Intelligent Network to a mobile user. 

Current Location: after a location attempt has successfully delivered a location estimate and its associated time stamp, 
the location estimate and time stamp is referred to as the 'current location' at that point in time. 

Deferred location request: a location request where the location response (responses) is (are) not required 
immediately. 

Global Positioning System: the Global Positioning System (GPS) consists of three functional elements: Space 
Segment (satellites). User Segment (receivers), and Control Segment (maintenance etc.). The GPS receiver estimates its 
own location based on the observed times of arrival of the satellite signals. 

Immediate location request: a location request where a single location response only is required immediately. 

Initial Location: in the context of an originating emergency call the location estimate and the associated time stamp at 
the commencement of the call set-up is referred to as 'initial location'. 

Last Known Location: the current location estimate and its associated time stamp for Target MS stored in the LCS 
Server is referred to as the 'last known location' and until replaced by a later location estimate and a new time stamp is 
referred to as the 'last known location'. 

LCS (Location Services): LCS is a service concept in system (e.g. GSM or UMTS) standardisation. LCS specifies all 
the necessary network elements and entities, their functionalities, interfaces, as well as communication messages, due to 
implement the location service functionality in a cellular network. 

NOTE: LCS does not specify any location based (value added) services except locating of emergency calls. 

LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. 
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting 
data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (MS). 

LCS Client Access barring list: an optional hst of MSISDNs per LCS Client where the LCS Ghent is not allowed to 
locate any MSISDN therein. 

LCS Client Subscription Profile: a collection of subscription attributes of LCS related parameters that have been 
agreed for a contractual period of time between the LCS client and the service provider. 

LCS Feature: the capability of a PLMN to support LCS Client/server interactions for locating Target MSs. 

LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider. 

Local Service: a service, which can be exclusively provided in the current serving network by a Value added Service 
Provider. 

Local Information: information related to a given location, or general information, which is made available in a given 
location. 

Location (/location detecting): location is a functionality, which estimates a geographical location (of e.g. a mobile 
terminal). 

Location (Based) Application: a location application is an application software processing location information or 
utilising it in some way. The location information can be input by a user or detected by network or MS. Navigation is 
one location application example. 
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Location Based Service (LBS): a service provided either by teleoperator or a 3"^ party service provider that utilises the 
available location information of the terminal. Location Application offers the User Interface for the service. LBS is 
either a pull or a push type of service (see Location Dependent Services and Location Independent Services). In 
ETSI/GSM documentation of SoLSA, LBS is called "Location Related Service". ETSI and/or 3GPP -wide terminology 
harmonisation is expected here. 

Location Dependent Service: a service provided either by teleoperator or a 3"* party service provider that is available 
(pull type) or is activated (push type) when the user arrives to a certain area. It doesn't require any subscription in 
advance, but the push type activation shall be confirmed by the user. The offered service itself can be any kind of 
service (e.g. a public Xerox machine or the discount list in a store). 

Location Estimate: the geographic location of an MS and/or a valid Mobile Equipment (ME), expressed in latitude and 
longitude data, and optionally altitude data. The Location Estimate shall be represented in a well-defmed universal 
format. Translation from this universal format to another geographic location system may be supported, although the 
details are considered outside the scope of the primitive services. 

Location Independent Service: a service provided either by teleoperator or a 3'^'' party service provider that is available 
and therefore can be activated anywhere in the network coverage. It is activated by the user's request or by other user's 
activated service, and therefore it requires a subscription in advance (pull type). The offered service itself can be any 
kind of service (e.g. MMS, SWDL, or LBS !). 

Location method (/locating method): a principle and/or algorithm which the estimation of geographical location is 
based on, e.g. AOA, TOA, TDOA. For example, GPS is based on TOA, and E-OTD (on GSM) is based on TDOA. 

Location technology (/locating technology): a technology or system concept including the specifications of RF 
interfaces, data types, etc. to process the estimation of a geographical location, e.g. GPS, E-OTD (GSM), and IPDL- 
TDOA (WCDMA). 

PLMN Access barring list: an optional list of MSISDN per PLMN where any LCS Client is not allowed to locate any 
MSISDN therein except for certain exceptional cases. 

Predefined area: a geographical area which is not related to cell or radio coverage. The mobile may take special action 
when it recognises it has entered or left a predefined area. 

Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to 
locate the target MS. The permission shall be granted either on activation by the target MS or permanently for a 
contractual period of time agreed between the target MS and the service provider. 

Privacy Exception List: a list consisting of various types of privacy classes (i.e. operator related, personal etc.). 
Certain types of classes may require agreement between the service provider and the target MS. 

Prohibited area: an area where the mobile must not activate its transmitter. The Prohibited area may be a Predefined 
area described above or related to radio cell(s). 

Subscription Profile: the profile detailing the subscription to various types of privacy classes. 

Target MS: the MS being located. 
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